Experience APIs with Four-Layered Architecture
This section details the design and implementation of the experience APIs functionality in Fabric only. For explainability, the Fund-Transfer scenario is an example throughout this document. The internals of the service endpoint, say a micro-service, are not in the scope of this document.
All the services for the Experience APIs are not supported using a four-layered architecture. For the list of APIs that support four-layered architecture, click here.
An Experience API exposes a set of services of related functionality. It is an encapsulation of the following components.
- Fabric Object Service, it’s Object(s) & Verb(s)
- Mapped Fabric Java Integration Service(s) and their Operation(s)
- Custom Code Invoked by the Java Integration Service(s) - Service Class(s), Resource Class(s) & Business Delegate Class(s)
- Fabric Integration Service(s) with external systems
Sharing the Experience API Functionality
An Experience API can be shared across multiple Fabric Applications for utilization by the linked end-client application, which is done by adding all the components of the experience API into the intended Fabric application. Sharing the functionality of an Experience API across multiple applications of the Temenos Digital Suite is done by sharing the corresponding business delegates only. Inter-app communication and the resulting extra network calls are avoided by doing so.
Structure
The structure of an Experience API by considering the example of Fund Transfer is illustrated here.
Object Service
An Object Service in an Experience API encapsulates all the Objects related to a particular functionality. Example: Objects such as Payment Order and Transaction related to Fund Transfer are grouped as an Object Service called Fund Transfer.
Object
An Object in an Experience API represents a particular entity related to the functionality served by the containing Object Service.
Example: A Fund Transfer Object Service may contain objects such as Transaction, Payment Order.
Verb
A verb on an object represents an operation allowed on that object. Example: A Payment Order object can have a verb that performs a P2P payment. A verb is linked to a Java Service Operation that performs the operation represented by the verb.
Service
An Object Verb is mapped to a Java Integration Service. The Java Integration Service hands over the request to the linked java class as part of the Service Layer.
Service Layer
The Service Layer consists of Java classes that are each mapped to an operation of the Java Integration Service. A class that is a part of this layer only performs the logic of reading the inputs from the input- map and passing them to the right method in the Resource-Layer. Below is an example of a Service class.
public class PartyCreateOperation implements JavaService2 {
@Override
public Object invoke(String methodID, Object[] inputArray, DataControllerRequest request,
DataControllerResponse response) throws Exception {
//Get the instance of the Resource class that handles this particular request
PartyResource customerResource = DBPAPIAbstractFactoryImpl.
getInstance()
.getFactoryInstance(ResourceFactory.class).getResource
(PartyResource.class);
//Pass the methodId, input parameters and other middleware specific objects to the Resource class
Result result = customerResource.createCustomer(methodID, inputArray, request, response);
//Return the operation Result return result;
}
}
Resource Layer
The Resource Layer is responsible for handling the incoming requests by handing them over to the appropriate Business Delegate classes. The request hand-over is done using well-defined Data Transfer Objects (DTOs) and primitives. Note that no middleware-specific object such as the DataControllerRequest is to be passed to the Business Delegate layer. A typical Resource class performs the following.
- Construct the DTO(s) by reading the input from the middleware-specific components such as the input-map and the DataControllerRequest.
- Obtain an instance of the required Business Delegate class.
- Invoke the required business operation in the Business Delegate class by passing the constructed DTO(s).
- Set the result returned by the Business Delegate Class into instances of middleware-specific components such as the com.konylabs. middleware.dataobject.Result class.
public class PartyResourceImpl implements PartyResource {
private static final Logger LOG = LogManager.getLogger
(PartyResourceImpl.class);
@Override
public Result createCustomer(String methodID, Object[] inputArray, DataControllerRequest request,
DataControllerResponse response) { Result result = new Result();
// Construct DTO by reading the inputs from the middleware specific components
PartyDTO customer = populateCustomerDetails(request);
// Fetch the instance of the Business Delegate class
PartyBusinessDelegate customerBusinessDelegate = DBPAPIAbstractFactoryImpl.getInstance()
.getFactoryInstance(BusinessDelegateFactory.class). getBusinessDelegate(PartyBusinessDelegate.class);
// Execute the business operation
String id = customerBusinessDelegate.createCustomer(customer);
// Construct the service response using middleware specific components
result.addStringParam("id", id); result.addOpstatusParam(0); result.addHttpStatusCodeParam(200); result.addStringParam("message", "Customer created
successfully");
return result;
}
protected PartyDTO populateCustomerDetails(DataControllerRequest request) {
PartyDTO customerDTO = new PartyDTO(); customerDTO.setName(request.getParameter("name")); customerDTO.setGender(request.getParameter("gender")); customerDTO.setSsn(request.getParameter("ssn"));
return customerDTO;
}
}
A Resource Class may be used by multiple Service classes (classes from the Service-Layer). In a case like this, the Resouce Class will have multiple methods in its contract.
Delegate-Layer
The Delegate-Layer executes the actual business logic that serves the request.
- Network calls to external LOB systems or the application database are performed from this layer. Note that integrations to external LOB systems or the application database must be done by using the right Fabric Adapters (Integration Services).
- A class that is a part of the Delegate-Layer must be designed in a reusable manner.
- Functionality must be broken down into granular methods to ensure easy extensibility & reusability.
Below is an example of a Business-Delegate class.
public class PartyBusinessDelegateImpl implements PartyBusinessDelegate
{
protected static final Map<String, PartyDTO> customers = new
HashMap<>();
@Override
public String createCustomer(PartyDTO customer) { String id = UUID.randomUUID().toString(); customer.setId(id); customers.put(customer.getName(), customer); return id;
}
}
Build Process
The project build POM is located in the directory REPO_ROOT/Fabric/Apps/java/pom.xml. The template can be built by executing the maven command ‘mvn clean install’ at this location. The build artifacts are exported to the directory REPO_ROOT/release.
Repository Structure
The general repository structure has been detailed in the below diagram.
Apps
Contains an export of the Fabric app(s) in an unzipped format.
Java
Contains the Custom Code in the form of Maven Modules, the Release Artifacts assembly plugins & the application aggregator.
JS
Contains the Pre-Processor and Post-Processor code that has been written in Javascript.
Release
Contains the build outputs and the release artifacts. The contents of this folder are generated when the install goal is executed on the main aggregator.
In this topic